A common model for network processing consists of a multi-level approach. This is common in many. Ethernet LAN protocols such as IEEE 802.3. The model typically includes 3 major levels, namely (a) Top:Logical-Link control; (b) Middle: Medium Access Control (MAC); and (c) Bottom: Physical interface (PHY).
A wireless LAN configuration compliant to IEEE 802.11 is similar to its wired counterpart and has the same three levels. Traditionally, the top Logical-Link control tasks are handled by software running on a HOST processor. The middle level is the responsibility of a MAC processor, which handles all frame traffic between the HOST and the PHY level.
In a typical wireless local area network (WLAN) configuration, a portable or mobile device (e.g., laptop personal computer) normally includes a PCI card or PCMCIA card. On this card resides a Medium Access Control (MAC) processor (e.g., an embedded processor), a PHY (physical layer) processing device (e.g., a digital signal processor), a shared memory and a shared bus. The MAC processor is a multi-functional processor engine responsible for a variety of different processing tasks associated with the wireless communications. The PHY processing device performs such functions as encoding/decoding waveforms. The memory is shared by a HOST processor (e.g., the main processor of the portable or mobile device where the PCI card is plugged into) and the MAC processor, via the shared bus. The HOST processor accesses the shared bus through a HOST interface (e.g., a PCI or PCMCIA interface) so that it can get access to the shared memory. The HOST processor may need to access the shared memory for a variety of reasons, such as: (a) writing commands to the MAC processor, (b) reading MAC processor status or response to commands, and (c) reading/writing of network packets via the MAC processor.
Commonly, the upper level logic link layer tasks done by the HOST processor have timing requirements that are much more relaxed, compared to the tight timing requirements for the MAC processor operating in accordance with such standards as IEEE 802.11. Thus, the HOST processor actions have a lower priority in general compared to the MAC processor actions. Furthermore, the priority of the tasks done by the MAC processor can be further subdivided. Many of the tasks performed by the MAC processor demand high priority, such as receiving(RX)/sending(TX) data via the PHY processing device, or decrypting data. Other tasks, such as defragmenting of packets to be later off loaded to the HOST processor are lower priority tasks. At other times, the MAC processor may be in an idle state when no processing is needed from the PHY or HOST processor. When an active RX or TX operation is in progress, access to the shared memory by the HOST processor can severely impact the throughput, since the high priority tasks of the MAC processor demand that MAC processor cycles be spent on processing data being received or transmitted to/from the PHY. However, the shared memory impact when the MAC processor is performing a low priority action has negligible effect on throughput.
One prior art approach to the problem of competing requests by the MAC processor and HOST processor for access to the shared memory has been preemptive multi-tasking using context switched threads of code. However, handling of the HOST processor cannot be done entirely with allocation of a programming thread to handle all HOST processor actions. In this regard, at times the HOST processor needs direct access to the bus, which it must also share with the MAC processor for accesses such as DMA (Direct Memory Access). This bus could also be used by the HOST processor for instruction fetch, as well as read/write cycles that access the shared memory which cannot be handled with a software code thread.
With such an open memory model great power and flexibility is provided for the MAC and HOST processors. However, it is impossible for the MAC or HOST processors to predict an access to the shared bus, since the MAC and HOST processors may be performing different actions at the same time. For example, the HOST processor could be sending a packet to the MAC processor for later transmission, while the MAC processor is receiving a high priority frame from the PHY processing device. Therefore, the HOST processor activity is nondeterministic and asynchronous with respect to the MAC processor; and since the HOST processor is completely unaware of MAC processor state, preemptive multi-tasking with threads is not a complete solution. In this regard, software-based threads cannot coordinate or control memory access of the HOST processor on a timely basis.
Other prior art approaches, such as locking and unlocking of the shared bus at time critical instances have too much overhead, and may be prone to problems common with locks, such as “starvation” and “deadlock.” It is also difficult to determine just when is something ‘time critical’ and when it is not, since there is no concept of processor state. Furthermore, prior art approaches that do burst access (e.g., DMA) from the HOST processor to the shared memory are efficient, but may prevent processor access for a long period of time. This may be unacceptable if the MAC processor is performing a high priority action and requires the shared bus, since it will be stalled until the long DMA burst of accesses are complete.
The present invention addresses these and other drawbacks of prior art approaches to arbitration for shared resources, as will be described below.